home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9610 / 000034_owner-urn-ietf _Thu Oct 10 00:14:55 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id AAA05443 for urn-ietf-out; Thu, 10 Oct 1996 00:14:55 -0400
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id AAA05438 for <urn-ietf@services.bunyip.com>; Thu, 10 Oct 1996 00:14:48 -0400
  3. Received: from dns2.noc.best.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA02236  (mail destined for urn-ietf@services.bunyip.com); Thu, 10 Oct 96 00:14:46 -0400
  5. Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id VAA13920; Wed, 9 Oct 1996 21:14:17 -0700
  6. Date: Wed, 9 Oct 1996 21:14:17 -0700 (PDT)
  7. From: "Gregory J. Woodhouse" <gjw@wnetc.com>
  8. To: Michael Mealling <michaelm@rwhois.net>
  9. Cc: Larry Masinter <masinter@parc.xerox.com>, michaelm@internic.net,
  10.         rdaniel@acl.lanl.gov, urn-ietf@bunyip.com
  11. Subject: Re: [URN] advantages of NAPTR over PURLs
  12. In-Reply-To: <325C6353.474E@rwhois.net>
  13. Message-Id: <Pine.SGI.3.95.961009205216.11077C-100000@shellx.best.com>
  14. X-Url: http://www.wnetc.com/
  15. Mime-Version: 1.0
  16. Content-Type: TEXT/PLAIN; charset=US-ASCII
  17. Sender: owner-urn-ietf@services.bunyip.com
  18. Precedence: bulk
  19. Reply-To: "Gregory J. Woodhouse" <gjw@wnetc.com>
  20. Errors-To: owner-urn-ietf@bunyip.com
  21.  
  22. Actually, the fact that the NAPTR proposal uses DNS as part of its
  23. infrastructure doesn't seem to me to be a huge issue. The reason is that
  24. under the NAPTR proposal namespaces are completely abstract, and it would
  25. be possible to implement those same namespaces using an entirely different
  26. mechanism. In fact, with a judicious use of replication, I don't see why it
  27. wouldn't be possible to smoothly transition to a new URN resolution scheme
  28. and have the process be completely transparent to users. Of course, this is
  29. conceptually possible with PURLs (because http://www.purl.org/* could be
  30. treated as an abstract namespace) but it does tie us to namespaces of a
  31. rather restrictive form.
  32.  
  33. Incidentally, I find this whole thread rather useful. I had originally
  34. planned to give a 1 hour brownbag presentation to some of my co-workers on
  35. URNs an the NAPTR proposal. Basically, this would have been part 2 of the
  36. DNS class I gave last week. Anyway, it was postponed/cancelled because of
  37. other priorities, but preparing for this presentation was an interesting
  38. experience. One reason is that I was forced to consider how I would respond
  39. to the question: "What is it about this resolution scheme that justifies its
  40. complexity?" Of course, I never actually had to answer that question, but
  41. I was certainly dreading it.
  42.  
  43. One final comment: I agree that there is no real need for a large number of
  44. resolution protocols, but I don't see this as a problem with the NAPTR
  45. proposal. Rather, I prefer to think of the proposal as purposely not
  46. specifying the actual protocol(s). This doesn't seem to me to be a design
  47. flaw, but just the opposite. In general, it i just good software
  48. engineering to keep the various components of a system a loosely coupled as
  49. possible, and this is just what the proposal does.
  50.  
  51. ---
  52. Gregory Woodhouse     gjw@wnetc.com
  53. home page:            http://www.wnetc.com/
  54. resource page:        http://www.wnetc.com/resource/
  55.